Offline clients and Occasionally Connected Devices (OCDs) need a way to persist changes carried out locally while they are offline. Once they are online these changes can be streamed to the remote server for further processing and storage. There are several reasons a client or a device may need to be offline. For example, in modern day scenario, though internet connectivity is available in most public places but may be unavailable in certain client locations for the sake of security. Another reason to accomplish a set of actions offline and then synchronize the changes with the remote server is to lessen the load on the remote server trying to support several users logged in at once. Also since offline activities are accessing local storage there is a performance improvement over fully connected devices which are always connected to the remote server and need to access remote storage.
US20090171679 filed by Salgado et al. teaches that architecture for uninterrupted access to business data by enabling work on rich client machines to be stored in a local business data cache that is always available. A dispatching mechanism executes read/write requests against the local cache transparently to a client application, an automatic synchronization mechanism propagates changes bi-directionally when the client goes online and a live connection with the corresponding backend data source is available. A declarative data access model is employed based on operation stereotyping and grouping that enables client applications to transparently execute create, read, update, delete, query (CRUDQ) and association operations against the local cache as if executed against the actual business data source. The architecture supports the offline creation of entities and sets of related entities when the entity identifiers are generated by the business data source and offline navigation of entity associations when foreign keys are not present in the related entities. It supports the concept of offline behavior and improves the performance of the offline or thin client. However, the database used in this invention is structural replica of the RGDb, so it consumes more footprint memory of the device and more complex to maintain structural replica of the RGDb in the offline or thin client.
U.S. Pat. No. 7,546,286 filed by Dickinson et al teaches that methods, systems and computer products are provided for allowing bi-directional communication between a database application and a remote data source and for allowing updating of data on a remote data source with data edited or created at a client site remote from the remote data source during an offline data editing or entry session via a client database application. It supports the concept of offline behavior and improves the performance of the offline or thin client. However, the database used in this invention is relational at the RGDb, so creating and maintaining all relationships which are present in the RGDb within the local database are prohibitive in enterprise applications.
In case of data sharing between multiple hosts and data servers, for efficient data sharing a light and easily maintainable local database deployment on the OCD is desirable. The said lightweight local database preferably be created and maintained locally. The general data management practices followed in the industry, especially for data sharing and dissemination includes enterprise applications having thousands of tables and terabytes of data on their remote servers. The local databases on the clients need to be populated with very user specific and context specific data. This particular need is address in the prior art and is being commercially practiced, wherein the local database on an OCD is instantiated as a replica of the RGDb in of the form of its structures and contents. This particular practice of replication of an instance of the RGDb on the OCD, upon querying by the user thereof, though useful, is not an efficient means. Precisely, taking into consideration the computational limitations of the OCD, the replicas so created on the OCD. This results in large and complicated database locally which would be very sparsely populated.
Another significant technical aspect in data sharing is of updating the databases at both the ends. The changes made to the RGDb either in terms of structures or contents would have to be usually repeated locally, the said operation is accomplished by means of replication in the prior art. This operation would prove to be prohibitive for applications with large user bases. Microsoft Sync Framework is one of the commercial systems available in the market which typically exemplifies the solutions offered for updation. The product details are available at http://code.msdn.microsoft.com/sync.
The Microsoft Sync Framework is a tool to synchronize databases. It works between client servers or peer to peer setups. The sync framework is capable of synchronizing between relational databases. It is also capable of synchronizing between data sources such as XML files which are non-relational. Synchronizing screen based storage in non relational objects is possible using this technology. Synchronizing databases between client server setup is successfully, though not efficiently, implemented in the prior art. However, synchronization in a peer to peer environment is difficult to implement because of context specific and user specific data that is stored in the local database. Microsoft Sync Framework follows an approach of synchronize databases of peer computers connected to the network. These solutions are preferably suited to fully connected devices which have thick clients. For occasionally connected clients and thin clients, the synchronization offers technical problems of deployment and performance.
In one of the state of arts in this technology, Google Inc's product ‘Google Gears’ is recommended only for private computers because the database is used weren't encrypted. Google has launched and still in use ‘SQLite’ for local storage and for Gmail offline client (i.e. OCD). Hence, there is a strong requirement for encrypted databases.
The solution to the problems of deployment and performance improvement for OCD and thin clients are not being satisfactorily addressed in the prior-art. Alternatively, Adobe Air can be bundled with a SQLite database for creation and maintenance of the local database. This is done by inserting SQL statements within the Action Script code of the application. The application database in this case is stored in a single file at a designated location in the memory, thus offering quick access to the data and resolving the performance improvement issues. However, the said practice fails to simulate the structure of the actual full fledge database and still have issues related to deployment and maintenance of relations and DDL objects.
Therefore, while offline the OCDs perhaps are not capable to exploit the relational support and data accessibility features extended to it while it is online. Hence, there is an urgent need of an alternate solution for local deployment and maintenance of the database at the OCD. The solutions taught in the prior art for having an efficient local database deployment and maintenance specially for OCDs as well as offline/mobile/thin clients which are synchronizable with the RGDb have shortcomings from deployment, maintenance, and performance perspective.
More particularly, the shortcomings are that the local database is the structural replicas of the RGDb. If very user and context specific data was brought to the local database then the local database may be sparsely populated, but, the overheads of creating and maintaining all relationships which are present in the RGDb are prohibitive in an Enterprise application scenario where thousands of users would be having offline databases which would need to be centrally synchronized with the RGDb in terms of its structures. Yet another shortcoming with the prior art is concerning the use of replica databases, with the use of replica database at the OCD, the local database doesn't remain a light weight, which further adds to affecting the run time performance of the local database in online as well as in offline mode of operations.
Thus, in the light of the above mentioned prior art, it is evident that for run time performance enhancement, simple deployment, and maintenance, there is a need to create lightweight local databases for as OCD including future smart data access devices, mobile/thin/offline clients. Yet another urgent requirement is achieving optimum synchronization while sharing of data between the OCD and the RGDb.